 UTP(UML Testing Profile) Profesori indrumatori:Stefan Stancescu Catalin Sandu Studenti: Marcu Dragos Alexandru Teodor Chiretu Nicolae Grupa 443A Cuprins 1 Prezentare generala(Marcu Dragos Alexandru) 2 Structura unui UTP(Marcu Dragos Alexandru) 3 Profilul(Marcu Dragos Alexandru) 4 Metamodel MOF(Chiretu Teodor Nicolae) 5 Date pentru testare(Chiretu Teodor Nicolae) 1 Prezentare generala Aceasta sec?iune ofera o privire de ansamblu ?i introducere în profilul UML de testare UML-ul de testare a profilului define?te un limbaj pentru proiectarea, vizualizarea, specificarea, analiza, construirea, ?i documentarea artefactelor de sisteme de testare Este un test de modelare de limbaj care poate fi utilizat cu toate obiectele majore, tehnologii ?i componente pentru sisteme de testare aplicate în diverse domenii de aplicare UML de testare a profilului poate fi poate fi utilizat independent pentru manipularea de artefacte de testare sau într-o maniera integrata cu UML pentru o manevrare a sistemului ?i de testare a artefactelor împreuna UTP-ul este definit prin utilizarea abordarii metamodeling-ului de UML Acesta a fost proiectat în urma principiilor de proiectare în minte: • Integrarea UML: ca un profil real, UML, profilul UML de testarea este definita pe baza metamodelului furnizat în volumul suprastructural UML ?i urmeaza principiile profilului UML a?a cum sunt definite în infrastructura UML Volumul de UML 2 0 • Reutilizare ?i minimalitate: ori de câte ori este posibil, Profile UML de testare face uz directa a conceptelor ?i UML le extinde ?i adauga noi concepte numai în cazul în care este nevoie Doar acele concepte sunt extinse / adauga la UML, care au fost demonstrate în software, hardware, ?i protocolul zona de testare sa fie relevante centrale la Defini?ia de artefacte de testare ?i nu fac parte din UML Fiind un profil UML, Profile UML de testare mo?tene?te caracteristicile UML: • Stratificarea: preocupari distincte din metalayers de abstractizare (de-a lungul arhitectura metamodel 4 straturi) • Compartimentare: utilizarea de pachete pentru structuri grosier sau fin granulate • extensibilitate: profilare profilul de testare pentru o adaptare la anumite platforme (de exemplu, J2EE / EJB, NET / COM +) ?i domenii ( de exemplu , finan?e , telecomunica?ii , industria aerospa?iala ) 2 Structura Profile UML de testare UML Testarea Profilul este organizat în patru grupuri logice de concepte : • arhitectura de testare definirea conceptelor legate de structura de testare ?i configurare de test • date de testare definesc concepte pentru date de testare utilizate în procedurile de testare • Comportamentul de testare definirea conceptelor legate de aspectele dinamice ale procedurilor de testare • timp de testare definirea conceptelor de o defini?ie timp cuantificata de proceduri de testare UML Testarea Profilul este specificata de : • Acordarea terminologia pentru o în?elegere de baza a UML de testare conceptele de profil • Definirea UML 2 0 metamodelului bazat de UML testare profil • Definirea unui model MOF pentru pur Profilul UML Testarea permite utilizarea de testare independent de profil UML • Exemple Acordarea pentru a demonstra utilizarea Profilul UML de testare pentru testele la nivel de componente ?i la nivel de sistem • conturarea mapari de Profile UML de testare pentru a testa medii de execu?ie , precum ?i JUnit TTCN - 3 Toate sec?iunile formeaza defini?ia Profile UML de testare În caz de ambiguita?i , metamodelului UML 2 0 bazate ia prioritate 3 Profilul 3 1 Test de Arhitectura Aceasta sec?iune cuprinde conceptele necesare pentru a descrie elementele care cazurilor de testare definite folosind profilul Aceste elemente includ contextul de testare, care con?ine o colec?ie de cazuri de testare Aceste cazuri sunt realizate printr-un set de testare componentelor Verdictul a unui caz test este determinata de o punere în aplicare a interfe?ei arbitru Arbitru Arbitru este o interfa?a predefinita prevazut cu profilul de testare Scopul unei implementari arbitru este de a stabili verdictul final pentru un test Aceasta determinare se face în func?ie de un anumit strategie de arbitraj, care este prevazuta în punerea în aplicare a interfe?ei arbitru Interfa?a arbitru ofera doua opera?ii pentru utilizarea în cadru verdict: getVerdict ?i setVerdict Opera?iunea setVerdict este utilizat pentru a furniza informa?ii actualizate la arbitru de o componenta de testare cu privire la statutul actual al cazului de testare în care aceasta participa Fiecare ac?iune de validare determina func?ionarea setVerdict privind punerea în aplicare a fi arbitru invocat (a se vedea punctul 6 3 2, "testul de comportament", la pagina 14 pentru mai multe informa?ii cu privire la ac?iunile de validare ) Fiecare context de încercare trebuie sa aiba o punere în aplicare a interfe?ei arbitru, iar vânzatorul instrument instrumente construirea pe baza Profilul de testare va oferi un arbitru implicit pentru a fi utilizat în cazul în care nu este definit în mod explicit în contextul de testare Scheduler Scheduler este o interfa?a predefinita prevazut cu profilul de testare Scopul unui planificator implementare este de a controla executarea diferitelor componente de testare Programatorul va pastra informa?ii cu privire la care exista componente de testare la orice moment, ?i va colabora cu arbitrul sa-l informeze atunci când este timpul sa emita verdictul final Se pastreaza controlul asupra crearea ?i distrugerea componentelor de testare ?i ?tie ce componente de testare a lua parte la fiecare caz de testare Fiecare context de încercare trebuie sa aiba o punere în aplicare a unui planificator Orice instrument trebuie sa furnizeze o astfel de punere în aplicare care va fi utilizat în cazul în care nu exista realizari explicite definite în contextul de testare SUT SUT este sistemul supus încercarii Ca profilul se adreseaza numai încercari de conformitate black-box, SUT ofera doar un set de opera?iuni prin intermediul interfe?ei la dispozi?ia publicului (s) Nu exista informa?ii cu privire la structura interna a SUT este disponibil pentru utiliza?i în caietul de sarcini de cazuri de testare folosind profilul de testare Elemente de testare Doua elemente de testare sunt definite în sec?iunea arhitectura: contexte de testare ?i componente de testare Un context de testare con?ine un colec?ie de cazuri de testare, o instanta a interfetei arbitru, în mod normal, o instan?a a SUT, ?i, eventual, la nivel înalt Comportamentul folosit pentru a controla executarea cazurilor de testare Componentele de testare sunt diferite elemente care interac?ioneaza cu SUT a realiza cazurilor de testare definite în contextul de testare Figura 1 0 Arhitectura de testare Arbitru ( o interfa?a predefinit ) Descriere Arbitru este o interfa?a predefinit definirea opera?iunilor utilizate de arbitraj de teste Cazuri de testare , contexte de testare , ?i runtime Sistemul poate folosi realizari de aceasta interfa?a pentru a atribui verdicte de teste ?i pentru a prelua verdictul actual al unui test Opera?iuni • getVerdict ( ) : Verdict Returneaza verdictul curent • setVerdict ( v : Verdict ) Seteaza o noua valoare verdict Semantica Stabilirea semantica verdictul este definit de clasificatorul realizarea interfe?ei arbitru Un exemplu de cum sa puna în aplicare opera?iunea setVerdict este urmatoarea : • În cazul în care un verdict este trecere , acesta poate fi schimbat la neconcludente , nu , sau doar eroare • În cazul în care un verdict este neconcludent , acesta poate fi schimbat la nu sau doar eroare • În cazul în care un verdict este nu , acesta poate fi schimbat la erori numai • În cazul în care un verdict este o eroare, nu poate fi schimbat Descriere Scheduler este o interfa?a predefinit definirea opera?iunilor utilizate pentru controlul testelor ?i a componentelor de testare Nici unul dintre opera?iuni de Scheduler sunt disponibile la specificatorul UML Opera?iuni • Scheduler ( ) : Constructorul de Scheduler Acesta va începe SUT ?i arbitrul • startTestCase ( ) : Programatorul va începe caz test prin notificarea tuturor componentelor de testare implicate • finishTestCase (t : TestComponent ) : Records ca componenta de testare t a terminat executia sa din acest test Când toate componentele de testare implicate în cazul de testare curent au terminat, arbitru va fi notificat • createTestComponent (t : TestComponent ) : Records ca componenta de testare t a fost creat de un alt test de componenta Testare Componenta Descriere O componenta de testare este un clasificator structurat care participa la comportamente de testare O componenta de testare este de obicei o clasa activa cu un set de porturi ?i interfe?e Componentele de testare sunt utilizate pentru a specifica cazuri de testare în care interac?iunile dintre un numar de testare componente Comportamentul clasificator unei componente test poate fi folosit pentru a specifica un comportament redus test de nivel, cum ar fi testul scripturi, sau poate fi generat automat prin derivarea comportamentul din toate cazurile de testare în care are componenta parte atribute • Zona: Timezone Specifica fusul orar din care face parte o componenta de test (orare sunt discutate în Sec?iunea 6 3 4, "Concepte Timp", la pagina 29) Semantica Atributul zone este disponibil în timpul rularii, ?i GetTimezoneAction ?i SetTimezoneAction sunt utilizate pentru a ob?ine ?i a seta fus orar în run-time Reprezentarea run-timp a zonei de fus orar nu este specificat Zona de fus orar ini?iala a componentei este specificat în model ca valoare taguri pe atributul zonei Notatie Nota?ia pentru componenta de testare este un clasificator cu stereotip > TestContext Descriere Un clasificator structurata care ac?ioneaza ca un mecanism de grupare pentru un set de cazuri de testare Structura compozita unui context test este denumite în continuare configura?ie de încercare Comportamentul clasificator de un context test este utilizat pentru controlul de testare atribute • arbitru : Arbitru [ 1 ] Realizeaza interfa?a arbitru • planificator : Scheduler [ 1 ] Realizeaza interfa?a planificator constrângeri [ 1 ] Un context testat trebuie sa con?ina exact un bun realizarea interfe?ei Arbiter [ 2] Un context testat trebuie sa con?ina exact un bun realizarea interfe?ei Scheduler Notatie Nota?ia pentru context test este un clasificator cu stereotip > Testul de Comportament Zona de comportament încercare include concepte pentru a specifica comportamentul de teste în cadrul unui context de testare Caz test publice opera?iunile context încercare sunt cazurilor de testare care reprezinta interfa?a fa?a de testeri În plus, pot exista alte cazuri de testare sau private protejate, care sunt folosite ca utilita?i în realizare concreta a cazurilor de testare publice Punerea în aplicare a cazurilor de testare este specificata printr-un comportament de testare Comportamentul de testare poate include un numar de special constructe definite de profilul de testare Un test va reveni un verdict Verdict Verdictul este o tip de date predefinit enumerare care con?ine cel pu?in valorile nu, neconcludente, trece, indicând eroare modul în care a efectuat acest test de execu?ie caz Un verdict pasa indica faptul ca în cazul de testare este de succes ?i ca SUT a comportat conform cu ceea ce ar fi de a?teptat Un verdict nu pe de alta parte, arata ca SUT nu se comporta conform specifica?iei Un verdict neconcludente înseamna ca executarea test nu poate determina daca SUT func?ioneaza bine sau nu Un verdict eroare spune ca sistemul de testare în sine ?i nu SUT nu Verdictul final al unui test este determinata de un arbitru Fiecare context de testare are un arbitru ?i voin?a furnizor instrument ofera un arbitru implicit în cazul în care contextul de testare nu specifica în mod explicit unul În timpul executarii test al comportamentului de testare, fiecare componenta de testare va raporta verdicte de arbitru, arbitrul va ?i produce verdictul final de la aceste verdicte specifice de componente de testare intermediar atunci când toate componentele de testare au terminat executarea acestei caz test Interfa?a arbitru predefinit define?te setVerdict ?i getVerdict care pot fi utilizate direct, daca arbitrul este descris explicit Chiar implicit arbitrul poate sa apara în mod explicit în caietul de sarcini ale comportamentului de testare În plus, profilul de testare a definit cateva ac?iuni care pot fi aplicate de componente de testare pentru a defini ?i sa observe verdictul Ac?iunea ValidationAction este un mesaj setVerdict implicit la arbitru se informa despre un intermediar (sau final) verdict locala din care componenta de testare Implicit O specifica?ie UML nu este neaparat completa Pentru a fi completa în acest sens înseamna ca specifica orice posibil urma de execu?ie În special în cazul în interac?iuni sunt utilizate pentru a specifica comportamentul, situa?ia normala este ca caietul de sarcini este par?iala specificând doar în detaliu acele scenarii care sunt de o importan?a deosebita Într-un context de testare, cu toate acestea, exista o nevoie sa ave?i defini?ii complete, astfel ca numarul de execu?ii de caz test de eronate pot fi pastrate la un nivel minim Specifica?iile implicite sunt unita?i de specifica?ii definite în profilul de testare ca un mijloc de a face defini?ii par?iale de componente de testare complet într-un mod compact, dar flexibil Testarea Profilul define?te mecanisme pentru implicite pe Interac?iuni precum ma?ini de stat Ideea generala despre valorile implicite este urmatoarea O specifica?ie comportament de testare de obicei descrie normativ sau comportamente a?teptate pentru SUT Cu toate acestea, în cazul în care în timpul execu?iei de test se constata un comportament nea?teptat, apoi un default se aplica handler Am inclus defini?ii comportamentul implicit pe mai multe niveluri diferite În cazul în care cel mai intim implicit nu sa recunoasca comportamentul observat, implicit de nivelul urmator este încercat 4 Metamodel MOF Aceasta sec?iune ofera o metamodel statator pentru profilul UML Testare Aceasta metamodel este un exemplu de MF metamodel, oferind posibilitatea ca MF instrumente pentru a se conforma cu standardul Profile de testare bazate pe Conformitatea furnizate de metamodelului MOF pe baza de este limitata la elementele de arhitectura ale trasabilita?ii permi?ând Testare profil ?i de gestionare a activelor de testare din întreaga instrumente Mai exact, aspectele comportamentale ale profilului de testare sunt lasate în afara metamodel curent, deoarece acestea nu ar furniza nicio îmbunata?ire susbstantial peste acest obiectiv, solicitând în acela?i timp o importanta partea din metamodelului UML 2 0 pentru a fi incluse în metamodelului statatoare Prezentam diagramele metamodelului MOF ?i sa furnizeze informa?ii mai detaliate, deoarece se refera la metamodelului A majoritatea conceptelor din profilul de testare sunt, de asemenea, prezente în metamodelului Cu excep?ia informa?iilor referitoare la profilul aliniere cu UML 2 suprastructura adoptate specifica?ii, informa?iile furnizate în sec?iunea profilului se aplica ?i metamodelului MF bazat daca nu vom furniza alte informa?ii ?i sa prevada ca înlocuie?te informa?iile de la sec?iunea de profil Testul de Arhitectura si testul de comportament Conceptele de arhitectura de test sunt legate de organizarea ?i realizarea unui set de cazuri de testare conexe Acestea includ contexte de testare, care sunt formate din unul sau mai multe legate de cazuri de test Cazurile de testare sunt poten?ial realizate prin elemente de încercare, iar verdictul a unui caz de testare este atribuit de catre un arbitru În mod similar, conceptele de comportament de testare descrie comportamentul a cazurilor de testare care sunt definite într-un context de test asociat cu cazuri de testare sunt obiectivele de testare, care descriu capacita?ile caz test ar trebui sa le valideze cazuri de testare constau de comportament care include ac?iuni de validare, care actualizarea verdictul un caz test, ?i log ac?iuni care scrie informa?ii într-un jurnal de testare Concepte de comportament includ, de asemenea verdicte care sunt folosite pentru a defini caz test rezultatele, ?i implicit comportament care este aplicabila atunci când este observat altceva decât comportamentul specificat 5 Datele de testare Conceptele de date de test a avea capacitatea de a specifica valori de date , codificari specifice asociate cu valori de date, ?i specifica?i wildcard , cum ar fi (orice valoare) " ? " ?i " * " ( orice valoare , inclusiv nici unul) Aceste caracteristici rudimentare sunt tot ceea ce sunt necesara în profilul de testare , ca ni?te constructe de nivel superior , cum ar fi seturi de date poate fi definit ca fiind componente de testare în cadrul standard sau furnizate de implementari specifice de scule Bibliografie -http://utp omg org/ -https://en wikipedia org/wiki/Unified Modeling Language -UML Testing Profile Specification, v1 0 editura OMG -http://www model-based-testing de/mbtuc11/presentations/Wendland etal-UTP-Tutorial 1 pdf 